Oh, my God.
Oh, my God.
Oh, my God.
Survive the two minutes, I guess.
Also, as a courtesy to everyone in here,
please turn off your cell phone and paging devices.
I hate it when those things ring.
They're distracting.
They're distracting.
So please, just, if you can be courteous,
just turn them off.
Thank you.
Otherwise, I'll have to get a cell phone jammer next year,
and I don't want to have to do that.
Air Ideas.
I have looked at no less than,
well, let's look.
There's Network Flight Recorder.
There's Real Secure.
There's those horoscopes.
There's those horrible NT-based ones from Craptor.
I mean, Raptor.
Sorry.
Accident Technologies.
They don't call them that for nothing.
And they basically all have a problem.
None of them are integrated.
They yell at you, and they scream,
and they don't do anything.
And more often than that,
I regard an IDS largely as a DOS against the operator.
It's what you call a human denial of service.
When you have a human being
who can only take in so much finite information.
Well, in IDS, I had the misfortune of looking at Real Secure.
And it has some nice features
if you want to snoop people's IRC traffic.
But the problem with it is it's noisy.
And one day, I got, just with the default set,
I got 300 email messages.
Do you know what I did?
I created a filter that automatically sends them to the trash
because I don't really care about all these things
that aren't really happening,
or they're happening wrong.
And they're just dumb.
It's like, basically, IDS technology
is like a virus scanner, but it only scans.
It doesn't clean, it doesn't quarantine,
and it doesn't do anything.
Who cares if you have a virus if you can't clean it?
So anyways, this is why I...
And a guy named Chris Kuth,
a really, really, really sharp Canadian fellow
who isn't here,
he's the OpenBSD portion of this.
I use OpenBSD.
I am not a god in it, so please forgive me
if I might spell it wrong.
Occasionally, I'm not a BSD god,
so please forgive me for that.
Anyways, I'm going to begin now.
A note of caution.
Automated response systems can cause more problems
than they solve.
These things that I'm presenting you
are nothing more than guidelines.
Denial of service in yourself is very easy.
Enemies more clever than you are.
Enemies in yourself can make life most miserable.
Nothing replaces vigilance, defense in depth,
keeping servers patched, and being sneaky.
Again, the reason I put this note of caution
is because what I'm suggesting,
I thought of it just today,
was basically, I'm given the equivalent of SAMs.
We now have radar, which is IDS,
but now you have SAMs,
which you can launch against incoming aircraft.
But if suddenly your SAM thinks
that your air traffic controller is a target,
things are going to get in trouble.
So this is just a note of caution,
that what I'm describing
and the flexible response systems
which I will be describing in here
can cause more problems than they cure.
So with that said, I'm going to continue.
Don't say I didn't warn you.
Deficiencies of typical IDSs.
They do not adapt and consider multiple
factors.
They only respond with things like resets or blocks.
They don't do anything, they just scream.
And they do not automatically stop an intruder.
One of the largest things I've heard here
is automated attack.
Well, why not automated defense?
Or even better, automated defense,
and if necessary, I don't advocate the use
of offensive force, but flexible response I do advocate.
And instead of just dropping a packet,
what if suddenly I start,
start logging, let the intruder think they've got in
and reroute them dynamically to a honeypot
as they're attacking my IIS server.
That's one kind of a dynamic response that you can do
instead of just a, oh, I'm reset packet.
I mean, that just seems lame to me.
I mean, with the AI technology that we have,
with all the clever and really cool hacks I'm seeing,
why can't we have clever responses?
Yes.
They're also expensive.
An average IDS sensor will run you
between $5,000 to $15,000 per sensor.
Now, I don't mind making people like NFR rich.
I don't have any problem against it.
They have a reasonable product.
At least it's not based on NT.
But when I see that it's that much,
and I say I want a place, I work in a trading environment,
and we have,
I think at last count,
at least 14 different networks
on like 15 different vendors.
And that's a lot of places where I'm going to place sensors.
At $15,000 a sensor,
that's a lot of money.
Now, people who are traders hate to spend money.
They love spending it if there's equities and risk.
You know, give me my money.
But ask them to spend $10,000 on a firewall product
and what's my ROI?
And then you say, oh, it makes you feel safe.
And then they laugh at you.
So this is kind of,
basically for the cost of a sensor,
$400 with a Celeron processor with a,
if you want to really be fancy,
buy yourself a $500 Intel Ether Express Pro
with four ports
so you can monitor up to four ports per sensor.
Now, if you don't have enough CPU,
well, that's a different question.
But it's definitely an option.
The signatures,
which are the heart of all IDSs today,
with the exception of anomaly-based,
are not updated fast enough.
I think,
I may be wrong,
but from a year ago when I was dealing with ISS,
they updated quarterly.
Maybe more than that now,
but it was roughly quarterly.
NFRs, I think,
were a little better monthly.
And I don't really know how RealSecure does it.
I haven't actually looked at theirs.
But even if it's a month, it's too long.
All of a sudden,
all these clever people here come out with,
say, 17 variants on a new exploit
for, God forbid, IIS.
And, you know, Unicode,
or, you know, some kind of a thing.
Because Microsoft, when they patch things,
they just patch the one thing.
Oh, it's a 256-byte-off,
but not a 257-byte-off set.
Because, you know, I mean,
they don't patch very well.
So, basically, because of the fact,
and this is another limitation,
is signature-based IDSs do not detect things
that they don't have signatures for.
So it's very nice to be able to have
other people all over the net
who are relatively intelligent
writing signatures.
You're also locked into a closed
and expensive solution,
if I, I mean, some of them do have languages,
but, like, for instance, the NFR,
the key exchange is absolutely a nightmare.
They use 56-bit DES,
and the keys never change, ever.
It's a shared secret between the client and the server.
And it's not even public key,
it's not even, like, 128-bit,
because, well, we couldn't figure out
how to get the license export or whatever.
And I don't like that.
I don't like being boxed in.
I like having flexibility.
I like being able to be sneaky.
And a lot of times,
it's very difficult
to be sneaky
with a lot of these commercial vendors.
Now, they do have their place.
I very much feel that
if you're in a Fortune 500
or trading firm
or financial firm like I am,
you probably need both,
simply because the people upstairs
really like to spend money,
in some senses,
which is counteractive to what I said,
but you have your one $15,000 sensor
and your 30 snort sensors,
and so they kind of think that,
oh, you're guarding the gates with a wheel,
and really, when snort's doing the work in the background.
Not that they know that, of course.
It's also harder to be clever
and integrate data across multiple sources.
All of the IDSs have woeful user interfaces.
One of the gentlemen yesterday
was talking about horrible user interfaces.
Well, IDSs have everybody beat.
I've never seen any of them
with decent user interfaces,
especially the alert screens.
There's too many of them,
too quickly for a human to absorb.
I mean, I can read, like, Moby Dick in a day,
and I don't like to see it.
I don't like to see 7,000 alerts
paging by me at, you know,
2,400 baud, even.
It's too fast.
So, anyways.
Here's my philosophy for error IDS.
Basically, an intrusion detection system
should be able to intelligently respond
to data from a variety of sources.
Hosts, networks, multiple points of view.
In other words, for instance,
from the point of view outside the firewall,
from the point of view on the DMZ on the firewall,
from the point of view on,
on my people going out to the firewall.
Because for those of you that NAT,
you know that telling what traffic is coming out
as it's NATed behind a firewall
makes finding out who's really downloading
all those Napster files very difficult.
Also, there's hosts.
Basically, the hosts are really important
because network traffic by itself
doesn't allow you to correlate.
Whereas with host stuff,
I'm talking things like you have an NT host
running Tripwire with a syslog monitor
with auditing.
Or auditing to Backlog
or there's 101 of those things for NT.
And this is the sneaky part
and I don't really mention it here.
You actually construct,
because you have an IDS,
you send the port 540 to nowhere.
But of course, you reconstruct it on the IDS
because you're listening to UDP port 540
bound for a non-existent IP address
for any of you that want to be sneaky with syslog.
So the attacker comes in,
ha, ha, ha, he's stupid.
He doesn't have any syslog server,
but yes, he does.
You just don't know he does.
Anyways.
Routing and switching.
Machine gear.
Anyways, those are just some of the sources.
Sources can even be, you know,
I mean, you know, routers, switches, firewalls.
I mean, and all kinds of other data sources.
I'm trying to be all-inclusive.
Am I speaking loud enough?
How is this?
Okay, I'll speak loudly from now on.
Continue on the philosophy.
Air IDS should never denial of service
in its own network.
Denial of servicing
is a very important thing.
It's a very bad thing,
especially when you're doing it to yourself.
And IDS should be mostly open components.
I said that because I don't really know
what license I'm wanting to go with.
GPL is really nice,
and then there's OpenBSD,
and there's all these silly licenses,
and I don't really know which one.
But I want it to be mostly open
because that way people can work on it
and realize that they're not going to make me rich.
I mean, that's not the object of this project.
The object of this project
is to provide a community-based IDS
that doesn't suck.
I mean, that's basically what this whole...
So anyways, that is the project goal.
You can tweak it because it's open source.
You've got the source code.
You've got the licensing.
And documentation's another thing.
I'm going to make sure
that the documentation is damn good
because I hate it when you download these things
and it says compile it this way
and you do and it doesn't work.
I mean, that is frustrating.
If you write documents, write them correctly
or don't write them
and let them figure it out for themselves
so they're not fooled into thinking
that your documentation actually works.
You can use it in ways
the original authors never imagined.
There are things that you can do
with Snort and Perl
and PHP and SSH
and all these open things
and you can combine them in a system
that is far greater
than the original intent of any of their authors.
I mean, using SSH to write dynamic firewall rules
is not something I've heard of.
I've heard of it being done on the host
but not being done...
from a central command processor
which I'll get into.
And finally, it's cheap.
I mean, not cheap in terms of labor
but even with these commercial IDSs
you're going to spend months tuning your network.
I don't care what anybody says.
You're going to have to know what your traffic is.
You're going to sit down there
with ethereal and TCP dump
and you're going to have to look at your networks
or you're going to have a useless IDS
because you have to tune it.
And everyone talks about that
but no one really stresses.
Tuning will take you a quarter.
I mean, if you're on a relatively large network
monitoring anywhere from 3% to 5%
to 6 network points
you're talking a lot of time.
I did a complete network evaluation
of just 6 network segments.
It took me a month.
I mean, because you're going through raw packet data
you're looking at stuff
you're having to talk to programmers
why are you using port 56789
through 60,000 for your application?
I mean, and you have to...
Oh, well, I also use 12345 and 678910.
I mean, there's these human factors
that you have to throw into the mix.
You just can't go with a protocol analyzer
and say, we use all these ports.
And not know who they are
and be able to intelligently look at what they are.
So I do want to really, really, really stress
the human factors involved in this system
are probably the most important.
Technologically, it's kind of a neat idea
but the human factors are the singularly most important.
Because, like I said, if you've got developers
working on programs and you don't know what they do
and it's like, oh my god,
why are they opening 50,000 connections per second?
Well, we're getting quotes from AT.
I mean, there's those kinds of things
that you have to know about your network.
So, anyways, I'm going to continue.
An IDS should not annoy.
When I get an alert from my IDS at 3 in the morning,
it had better well be an alert.
I don't want to get woken up at 3 in the morning
to know that some idiot's trying to run
the newest IIS exploit on me.
I patched it, have a nice day.
An IDS should be completely out of band
so it is undetectable.
Now, I will admit I have not researched
into the implications,
of using a bridging sensor.
I'm sure that they're detectable.
I'm not saying they're not.
But to your average attacker on the outside,
the only way I know of,
and please correct me,
the only way I know of to detect a bridging sensor
would be latency.
Because it's just sending them along.
I mean, because it's a layer 2 device.
It's open BSD.
So, as far as I know,
I actually did some measurements
and the only way I could tell
by looking at the packet
was that there was a tenth of a millisecond delay.
Between the time that it got
between the two interfaces.
So, it's kind of hard to detect.
The management portion of it,
I like to have out of band
because a lot of times there are flaws.
No matter what you do,
you probably will make a mistake.
So, if the IDS's management console
and all the components are located
on a completely out of band network,
there is no way that anyone,
or it's very difficult,
for anyone to get in and hack your IDS
and look at it.
Look at all the beautiful signatures.
It's less convenient for the admins,
but so what?
They get off their butts
and they walk to the server room
or you patch it into your cubicle
and do it that way.
I mean, at least it's somewhat more secure.
When they cut across?
Well, that's the advantage of using bridging.
Because there's no IP.
I mean, yes, there certainly are things
they can do to make your active response
act against you.
That kind of attack is quite possible.
But the sensor itself doesn't have an IP
on either side.
I mean, there are certainly certain kinds,
you could probably try to denial of service it
and whatnot.
But there are other preventative measures
that we can take to minimize and limit that.
IDS should have at most
one or two decision-making points.
Now, you do start running into a problem with this
in terms of performance
if you're monitoring large amounts of networks
using, essentially, I'm advocating the use
of a centralized SQL database
on one computer.
There's probably four or five processors
on a really big network.
Simply because it's less places for things to go wrong.
It's less places for attack.
If you keep some of the componentry down,
it's simplicity.
So you want to keep it as simple as possible
and yet at the same time,
maintain the flexible response.
So it's very important to have
one or two decision-making points.
An IDS should work in conjunction
with other protection systems.
Airwalls, the hosts themselves,
and routers.
They should be able to dynamically talk
to these components and if necessary
take action based on the
input of multiple sources.
And again, the whole
I'm trying to advocate is a union
of all these technologies that
everyone says, like, one people say network-based,
one people say host-based.
I say both in conjunction because neither of them
by themselves is sufficient.
And IDS's evidence
should be admissible in court.
There are a lot of really neat technologies
like worm drives and those,
if you've ever had the cool,
those HP jukeboxes with the flip disks.
And those are worms.
They're unalterable media.
Those packets have been written and logged
to those things.
And all the raw packets should be available.
The problem with basically any of the sensors is
you don't have the raw data.
So somebody who's in court can say,
well, your tool sucks.
So you can say, okay, here's the raw data.
And, you know, here's what the conclusions we can do.
And you can actually look at the raw data.
So having a packet vault is a very important thing.
And IDS should be OS agnostic.
That means it doesn't matter what OS,
it has to work on all of them.
I mean, not necessarily the sensors
or not necessarily the actual
hardware that runs it,
because I just can't really advocate
running most of these things on Windows.
It's just too scary.
I mean, it's, I just, I can't.
I mean, I'm just, I was trying to secure it.
This is a brief aside.
I was trying to secure an IIS server.
I was reading, the stupid thing runs as local system.
There is nothing I can do.
It runs as local system.
So if there's any new problems, it's got root.
So just put a reverse proxy in front of it
and be done with it.
I mean, that's really the only way I know how to secure IIS.
It's just put a squid proxy in front of it
and just filter out Unicode.
And get rid of all those IIS things and just send it.
And of course you get rid of no-ops, too, that way.
Well, you don't have a choice when you have a CIO
and silly developers who...
It's a reality of working in business,
is that I hate IIS.
And I managed to stop Exchange.
I'm quite proud.
But I could not stop IIS
because a lot of the kids coming out of college today
dare I say use Microsoft Foundation classes
and Visual Basic for their programming.
And lots of these people will be hired
because A they're cheap
and B the only thing they know is Microsoft.
And so weaning those people from that process is kind of hard.
So for any of you who doubt what I'm saying,
unfortunately Microsoft is a necessary evil
and it does keep us employed.
Just think of it that way.
Microsoft is so insecure that we will always have a job.
Anyways.
And yes, I know.
I'm not being OS agnostic.
Oh well.
The IDS is, yes.
And IDS should allow the analysis and analyst
the flexibility of looking at past data.
This is the snort portion of it.
I haven't really talked...
I'm not really going to get into the specifics
of using snort and ACID and all these other things.
But those are some of the...
All this is at this point...
The only thing that's real is the ability
to have a command processor
respond to input from a snort sensor.
And the concept of a bridging sensor.
Most people just have sensors.
This is why I have a sensor when you have bridging code.
So not only is my sensor a sensor,
it's a firewall.
So I happen to be running checkpoint
and there's the new horrible RDP attack.
My sensor basically...
I can put the firewall rule,
block all RDP from the outside.
My checkpoint never sees it
and I don't have to worry about patching
and causing my network to crash.
Because I'm sure you've all had upgrade fun.
Anyway.
Components of Air IDS.
This is actually...
Can someone tell me in an hour?
Because I'm just going to kind of
take a five minute break for everybody.
Because a lot of times you go on
with these two hour presentations
and you get kind of bored.
So I'm going to take a five minute break
after the hour mark.
And then I will begin immediately
after the five minute break though.
So if you're thinking of leaving or whatever,
you'll need to be back here then.
Anyways.
So the components of Air IDS.
The stealth sensor.
They are bridging firewalls with OpenBSD
and to be correct we use the...
It's PF rather than the other one
because of that licensing thing.
I still haven't figured that all out.
But anyways.
The centralized data gatherer.
The sensors and hosts report to this.
Typically this is going to be
an industry standard database.
Whether it be MySQL or Postgres.
The problem with MySQL is
if you have a lot of data coming in
it doesn't do transaction queuing.
And so you're just going to be in trouble.
Because MySQL will just choke.
Because it does blocking IO
when you start getting multiple data sources.
So you've got 17 snort sensors
reporting to one database.
And all of a sudden...
MySQL just can't handle it.
So at this point it's just a database.
I'm not going to say which.
But a database which can handle
transaction queuing and can do threads.
Because you're going to have to do threads
in order to keep up with the speed of the network.
And I'm not even talking about gigabit.
Anyways.
A historical comparison module.
This is what I regarded
as an anti-annoyance feature.
If you have a site say in...
Well let's not say China
because everybody said China today.
Let's say Russia.
You have all these annoying Russians
that are probing your network
and trying to hack you
and get their elite ware sites up.
Well I see this and I say
there's about five or six IPs
and I verify them.
Because you really don't want to react
based on historical stuff.
Because machines do exactly what you tell them.
And if they see a particular host
six times denial of service
well we all know what spoofing is.
Don't we?
Anyways.
So the historical comparison module
is more for a human to look at.
Are these hosts repetitive offenders?
Are they doing port scans?
Are they doing what I consider to be hostile traffic?
I'm very much an advocate
of what I call geographic profiling.
If a particular geography
is causing you problems
and you have no business
receiving web traffic.
For instance,
I work in a Chicago based trading firm.
There's no way that anyone from China
should be looking at my website.
I'm sorry.
We were proprietary markets.
There's no business reason
for me to be even accepting any traffic
except maybe email.
And even that questionable
from these hostile sites.
I recently saw a lot of these
HTTP scans from Beijing and other areas.
And I just got tired of it.
So I just said
209 dot star dot star dot star
block
and all my port scans stopped.
So anyways.
Yes I know it's racial
but sorry.
Anyways.
The command rules processor
for active filtering.
This is probably the most complex
part of the whole thing.
It's a separate module
which would have to use
an expert based system
to make intelligent decisions.
You just can't have something
if I regular expression
this signature do that.
You can do that
but you're going to have
some very dangerous rules
if you do.
So what I'm proposing
I don't have yet.
I've got a couple people
hopefully in the audience
who are really good at
expert system stuff.
I need a database
and what we can call
a response library.
We have not only a database
of hostile actions
but a response library
that can talk to the other modules
so that it reacts intelligently
to threats.
Intelligently and automatically.
And with all the processor power
that we have these days
why not have a really big
expert system?
I mean with a gigahertz penny
costing less than $500
there's no excuse.
There's no excuse not to.
So anyways
this command rules processor
what it does fundamentally
is it takes the input
consults with the expert system
and decides what it should do.
For instance
I'm running a trading firm.
I start seeing HTTP scans
and hostile IIS activity
from site X.
I'm running tripwire
at the same time.
I guess we'll run it hourly
because we can't run it too much
because I'm just one binary
otherwise you run out of processors
on poor little NT boxes.
And basically
all of a sudden
I see this traffic
and then on the host
the trading application binary
is suddenly modified.
Now this is probably a bad thing.
It means that my trades
are no longer trustworthy.
So that warrants an immediate response.
So it consults with it
and it says
oh this host
that problem
shut the connection.
Doesn't matter where it's from.
The reason why
is because it is such a catastrophic
condition.
It is better to stop the trading
than it is to go on trading
with unknown data.
Again
it depends on the site policy.
This is where the human factors come in.
You have to know
what an unacceptable condition is
and be sure to translate that
to your manager.
Say if this happens
we will lose connectivity.
Or if this happens
this will happen.
You have to be very clear
in the policies
and written procedures
that you have in your organization.
Again if you are
just doing it for yourself
don't worry.
But if you are in a fortune 100
or banking
or clearing corporations
like I have been in
if you suddenly stop service
and you are clearing
a billion dollars a day
you don't have a job very long.
So you do have to
bear these things in mind.
The command processor
essentially uses SSH
to talk to the sensor
on an out of band network.
Now you say
why do you bother?
Well we all know
about the problems with SSH.
I mean it is certainly
better than Telnet
but even with version 2
there are problems.
If it is out of band
well first of all
I have got an encrypted transmission
which is good.
But now it is an out of band
encrypted transmission.
So that an attacker
through the internet
I will say that
through the internet
or an outside
or even inside
without physical access
to my out of band network
cannot subvert the system.
Now it is relying on
physical security
of the boxes.
Obviously you don't want
to leave it out
in your kiosk area.
But anyways
what it does is
it sends an SSH command
pf block in source
my web server
if it sees that event.
And then send out a page.
That is one example
of a kind of response
that the command processor
could do.
Another kind of response
that you could do
would be say
I see
I just see suspicious web traffic
you know like
why are they doing
a hundred million dollar trades
when all we do are
you know like four lots
and eight lots
you know of trades.
So basically
it can look for
you can actually have
like a little processor
and then when it does
what you do is
you start recording
those packets
to your worm drive
or something there.
And in case there is fraud
and we have SEC unfortunately
we are trading
so we have to worry about that.
We can admit that
and if necessary
convict
this person
based on the packet vault.
So you can do
more intelligent
and you want the raw
packet data again
because it is
it is the raw
most form of the data.
It has not been distilled
it has not been altered
and in a court of law
as far as I can understand
it is the raw data
that is probably more important
although the distilled data
is very important
but the raw data
is a vital aspect of this.
The anti-shoot ourselves
in the foot module
contains host not to block
for instance it would contain
our infrastructure servers
never block my DNS
never you know
don't do dumb things
like block my partners
you know if I start seeing
hostile traffic from a partner
scream
but don't block them
you know
and just
and notify the partner
maybe send a message to the
you know the sysadmin
at the remote site saying
by the way it looks like
I'm receiving port scans
from your IP
can you check to make sure
you haven't been hacked
you know
and I wouldn't have to do anything
the whole system would do it for me
and that's what I'm talking about
with flexible
and intelligent response.
It doesn't denial of service
my partners
or my
you know
my web server
can talk to my DNS server
oh my god
port scan from DNS
block
end of game
I don't need to do that anymore
and you know
anyways
finally the last one's
kind of a pipe dream
I just threw this in
that you have a
heuristic
or learning mode
to make configuration easier
it'd be kind of nice
if you could just have
like you'd fill out
these little questionnaires
about your network
and it could come up
with a fairly basic
set of rules
that would actually be applied
because most people
are not going to have
the expertise
to go with TCP dump
on their networks
and do things
so kind of a
like those silly wizards
that ask you things
and to kind of
to some degree
have a very limited
response system
like what is your web server
what is your DNS server
who are your partners
and do you
and if one of
if I see an attack
from one of these
what do you want me to do
that kind of
heuristic
it's not really heuristic
but the learning
what I was thinking of
if any of you have used
Mason
it dynamically
watches the traffic
and then just
automatically generates
rules based on that
it's very dangerous
but very convenient
so it
it's just kind of
it's just kind of a thought
I don't really know
what to do with it
but anyways
the stealth sensor
it's a transparent
bridging approach
is used
this allows for
undetectable monitoring
well relatively undetectable
I'll say that
because I'm not
an expert on bridging
transparent firewalls
but it should be
relatively undetectable
traffic flows
can be stopped
because it's also
a firewall
redirected
or even reflected
back at an attacker
I don't know
I kind of like the new
IP
the new
this is a Linux plug
I kind of like the
reflect attack
the mirror target
on the new IP tables
is kind of cool
but anyways
finally
it makes it difficult
to attack the IDS itself
it's bridging
I would love to see
some attacks
on bridging IDSs
that would be
very interesting paper
I haven't seen any to date
I've seen nothing
that really
that talks about it
other than denial
of servicing them
finally
it doesn't prevent
fooling the filtering module
into doing something
bad or stupid
again
if the rules
are improperly made
an attacker can send
packets at you
knowing that you have
the system in place
and really
make life miserable
the sensors have
three interfaces
one for management
and two for bridging
ether express
nix
I've heard a lot of
banter
about which one's
the best
I personally use
three coms
but I have noticed
high CPU utilization
you probably
the ether express
Chris basically
recommended them
my friend
who's a Cisco person
said he saw
like five times
the throughput
on the new ones
you don't go with
the old ones
but the new ones
so anyways
and as you know
CPU utilization
and bus mastering
and all these other things
are quite important
on an IDS
sensors should be
based on
a reliable
network
and secure
operating system
OpenBSD as far
as I know
is one of the more
secure operating systems
on the planet
I will preface
that mainframes
are more secure
but anyways
they are
it takes 30 minutes
to enter a user
anyways
26 transaction codes
before you can
even log in
OpenBSD is relatively
easy to set up
due to its minimalist
philosophy
and secure design
for me to go through
the package selection
on SUSY
or any of the Linuxes
takes 4 and a half
to 2 hours
because there's
4000 packages
in SUSY alone
and I think
in the new Mandrake
there's like
3500
and so
and the default
package selections
are stupid
so you have to go
through every package
and so anyways
BSD is just
install at default
turn off the
you know
for some reason
they leave RPC open
just turn off the RPC
and it's pretty much done
OpenBSD,
Snort,
ACID
and the database work
the rest is going to be
a project
anyways
let's continue
the
anyways
let me continue
for those of you
who are here
this is a theoretical talk
I do have some
practical application
but unfortunately
I'm not a programmer
I'm
I'm okay at network stuff
but I'm not an expert
and so what I'm trying to do
is I'm trying to get together
like I said
a community based project
where we can get all these
different people
with different expertises
for non-profit
because if it's for profit
it just
everyone becomes selfish
and
then suddenly
it just doesn't work
so
this is kind of
an allotruistic vision
of
having
a community
based
intrusion detection system
that kicks
everybody else's ass
I mean that
that is really
what the vision
of this project is
so at the end
there's all kinds of resources
and I will continue with that
yes
you redirect
you can rewrite packets though
you can rewrite the packets in transit
between bridge one to bridge two
anything you want
that's the whole point
use dev random
I don't know
oh sorry
the question was
is if you don't have
a
IP address
how do you rewrite packets
headers
and I basically said
well
you rewrite the source address
and destination address
any way you want
because it's PF
you know
it's low level
you've got raw sockets
that's the whole advantage
of the OS
you write any source
or whatever
I mean
write
use it's own source address
if you want to be nasty
anyways
sensors
sensor descriptions
sensors communicate relevant traffic
via out of band
network to reporting module
sensors can receive commands via SSH version two
version one is hopelessly flawed
I don't recommend using it
unless you have no choice
it's better than telnet
but avoid one if you can
if you do use it
turn on compression
at least it makes
finding the passwords a little harder
sensors can dynamically
block
allow
ignore
reflect
or redirect
or log traffic
I didn't put that in there
sensors can also send out syslog
basically
the covert channel thing I talked about
where you
you just have all your hosts on the DMZ
basically sending to a mythical syslog server
but you're actually recording the syslog traffic
as it
as it comes in
and reconstructing it
based on that
it's
it's
it's for the event logging
and for some of the host based stuff
that you need
sensors will send data
to an industry standard SQL server
and one thing I should put in there
sensors will send data in a standardized format
or at least there will be some kind of
because I
originally was just going to use snort
but then I thought
well why don't we use all these other IDSs too
and so just basically
somehow parse their alerts
into a one to one equivalence
so that you get some kind of a standardized database
among all the different
of all the different vendors
I
obviously this is a huge task
but
it's a nice idea
data will be encrypted
I know it's an out of band channel but
a lot of people
well
out of band networks are a pain in the ass
so
let us use
Zebedee
it's a very nice
Blowfish encryption
it works on Windows
it works on Unix
it stands for Z
Zlib compression
Blowfish encryption
and it's really fast
and it's much faster than SSH
it supports
keys between servers
and
so basically you
you send your database connection through
an encrypted Zebedee tunnel
to the sensor
so
you don't have to
for the truly paranoid
it's there
centralized information repository description
the host is hardened
basically
you know you've done
the sensible things
taking out unnecessary services
no compilers
etc
runs a journaling file system
the nice thing about journaling file systems
is if you turn off the power
you don't lose your database
well guess what we have
we have a very large database
and
they don't take kindly to
power outages
and
to be honest
I really
ext2
kind of scares me
with databases
because it
it's fast
but it's
just kind of
squirrely at times
so
I personally use
a
a Suzy with Riser
some people say it's unreliable
I've been running it for
well
a year and a half now
and
haven't lost a single file
on a hundred
gigabyte file system
so
it's pretty reasonable
is it on
it's on a UPS
and obviously
has the UPS connector
connected to it
so if you lose power
it shuts itself down gracefully
now this means
that if you have a server
you make sure
that you're
you buy yourself a little
400
you know
APC 400
and it runs your server
for two minutes
that's silly
buy yourself a big APC
and then
then your database
can take as long as an hour
to shut down
if it's Oracle
God forbid
and
so
you need to make sure
that when you get a UPS
you get one that's big enough
for the wattage
or the ratings
and do a test
you know before you have
all your important data on it
unplug it
and see how long it lasts
under load
I mean
I know what the manufacturers
saying
volt hours say
but batteries go bad
you know there's all kinds of
all these other factors in them
it's regularly backed up
when I say it
the only thing I really refer to
is the database
if you're using MySQL
it's really easy
shut down the database
and tar up the directory
with other types of databases
it's a little more complicated
and
to be honest
I'm not really a database guru
I don't know
figure it out
it's on an out of band network again
it doesn't have to be
but
I recommend that it is
just because of the fact
that it's such vital information
and
from a privacy standpoint
when you're talking about deploying
a system like an IDS
especially in universities
you're recording all the traffic
and not only that
but you have a permanent record
of all the traffic
the privacy concerns
of protecting that kind of information
are huge
even if it's the company's data
the politics
and the levels of problems
that occur with this kind of information
are huge
I've seen people fired
I've actually had to have people fired
as a result of
sensor traffic
and it's a really hard thing to do
someone you like
and all of a sudden
they're doing kiddie porn
and it's against the policy
and have a nice day
go feed your children
it's pretty unpleasant
it's just unpleasant
and
I just
like I said
so it has to be
I think
just because of the fact
that it's repositorying
all the information
it has to be
on an out of band network
it doesn't have to be
but
again
because of the ethical concerns
in the kinds of data
that we're collecting
I think it's in your best interest
to do that
currently the only OS
that does most of this
out of the box
is Suzy Linux
Mandrake will do it
I don't know if there's
a journaling file system
for BSD out of the box
if there is great
Slackware?
Okay
well thank you
I haven't used Slackware
since 92
so please excuse me
okay
yeah
and Dead Rat
I just
it's better in the 7.1
but
but
it unfortunately
I just don't like
the way they do things
they don't use
any kind of
standards
they use that stupid
check config thing
to turn things on and off
and
just all their RCs
are in the wrong place
and I don't like
figuring that out
so that's just me
now you were saying
you're worried about
a journaling file system
but you're recommending
RAID 0
well that's why
we have backups
RAID 0
I'm sure you're all
uber hackers
but just in case
there aren't any
RAID 0 means
you stripe the disk
across two
so you have basically
twice the speed
but
half the reliability
because if either of the disks
go bad
you lose everything
so
you have a really fast disk
for less than
$400
I can have
a
160 gigabyte disk
which will do
50 megs a second
on an IDE channel
mind you
that's IDE
that's not SCSI
we're not talking
Ultra 166
or Sun Hardware
or 64 bit
PCI
I mean
50 megs a second
that's a lot of bandwidth
you're almost
saturating the bus
at that point
basically
the central
it has a host based
firewall
in the case of
Linux
you would be using
I would recommend
IP chains
until IP tables
stabilizes
but IP tables
is really nice
because you can do
MAC address checking
you can do
MAC address checking
you can do
all kinds of
flexible response
and basically
what it says is
even though you're
on an autoband network
only these hosts
can connect to me
so even if they get
physical access
or tap into the line
because you're not
using fiber
because most of us
can't afford
the fiber cards
to our desktop
anyways
so basically
all these things
can connect to me
on these ports
and whatever
sensors
and syslog
reconstruction
occurs
on this host
basically
the syslog input
is fed directly
to this host
and in parallel
to the system
I just like
to do a tail
on the text file
for any immediate
responses
that need
you know
right now
this is just one event
that doesn't need
to be correlated
that's catastrophic
or needs to be responded to
it just gives you
a really nice way
to send an emergency
rule out
to a sensor firewall
if you need to
again the central
basically it talks
to the central command
processor
stores all the data
syslog
ids data
host alerts
and tcp dumps
of all
I would say
not all data
but all relevant data
obviously if you're not
doing certain kinds
of things
you don't need
to monitor everything
but figure out
what you need
in your policy
it's the historical
comparison module
it talks to the
centralized information
repository
checks to make sure
that all the data
coming forward
it looks for
repeat offenders
and it checks
for port scan
repetitions
from hosts
it's largely
from nuisance users
or hosts
it can also be used
to detect
stealth port scans
again
imagine a database
that you never erase
I mean suddenly
you have
every person
who's ever
scanned you
since like
last year
I mean that's
that's very powerful
especially if you
start getting into
data mining
the command rules
processor
again this is
the heart of the
ids
it dynamically adjusts
the rules
based on attacks
in real time
it doesn't do
dumb things
because of the
anti shoot ourselves
in the foot module
it sends rule changes
via an encrypted
channel to the
sensor
it constantly
communicates
with the centralized
information
repository
and it can
interact with
firewalls
this last part is
is if
a lot of the
commercial firewalls
checkpoint
sunscreen
ans interlock
if anyone
has used that
firewall
it's like
way in the
past anyways
basically have scripts
that you can
dynamically add rules
so you can actually
on your main
firewall
do things
and again
it's just thrown in
as kind of a
it's an integration
feature
that you can actually
do
with your firewall
of course it requires
command line
facilities
on the firewall
to work
command rule
processor continued
it is able to
react to network
event
and host events
compares and
correlates the
results from
multiple sensors
to see if
sophisticated attack
is taking place
and it contains
a flexible response
in other words
if certain conditions
are critical
cut off all access
if only non critical
perhaps
page
or log
all of the
suspicious packets
from the hosts
how am I doing
for time
okay
thank you
the
again
the
command rule
processor
it can
block
problematic
hosts
via
historical
module
basically
these are
ones that
are not
in the
anti-shoot
ourselves
in the
foot
module
so I will not
be blocking
my DNS
server
can actually
tell what is
happening on
the host
itself
I like tripwire
because
combined with
a lot of other
techniques
it can tell you
if a file
is changed
now the problem
with tripwire
is if an attacker
gets in
and modifies
or gets rid of
the tripwire
process
obviously
you're out of
luck
but a lot of times
if you're sneaky
and rename
the
tripwire executable
write.exe
I mean
a lot of people
probably are not
going to figure out
that you have
tripwire
and you can actually
move things
to non-default
locations
now granted
it's security
through obscurity
but
everything you can do
to slow down
your attacker
gives you
more time
to defend
and that's
what the game
is
basically
can actually
and again
Unix syslog
I kind of like
syslog
a lot of people
say it's bad
it's so universal
and as long as you
do it out of band
people aren't going
to denial of service
you
it's harder
anyway
I mean
they can't like
spoof a host
and then go in
now with
the thing that I
described
someone could
conceivably send out
bogus UDP streams
from a host
you can use
things like
syslog next generation
but
I find that
it's kind of buggy
like it has
memory leaks
it's gotten better
the cryptographic
checksums
are very helpful
but again
if they've compromised
your host
they probably have
access to your keys
anyway
so why worry
custom alerts
again
there's different
kinds of ways
to be alerted
there's
like
snort has
the SMB server
message block
for your windows users
there's pagers
there's all kinds of
ways
this is kind of
an interesting
thing I just thought
of
it's kind of
a random thought
but instead of
representing a host
as something
impersonal
like have a picture
of something
like a person
and say that someone
denial of service
is your web server
all of a sudden
like a bullet hole
appears in the head
I mean
it would be
it would be kind of
a very graphical way
to show a manager
what's going on
because managers
don't understand
this
they don't
have the right
alert system
such as that
the command rules
processor
can take
corrective action
based upon a host
as well as
network inputs
the open source
network components
that I'm using
today
snort
ssh
zebedee
pearl
or
whatever
scripting language
of your choice
for those who
have other ones
15 minutes
did you want
to take a break
now
okay
we'll break
for five minutes
then
it's already
posted
it's already
posted
at the end
yes
thank you
very much
yeah
excuse
using
the product
very similar
to what
you're
talking
about
basically
the next
module
is the
anti-shoot
ourselves
in the foot
module
contains
lists of hosts
that should
never be
blocked
contains
trust
relationships
I don't
like
trust
relationships
but they're
a fact
of life
unfortunately
so if we
have trusted
